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METHOD AND APPARATUS FOR CONTROLLING FLUID PUMPS 

[0001] This application is a Continuation-in-Part Application of U.S. 

Application No. 09/030,989 filed on 26 February 1998, which is a Continuation 
of U.S. Application No. 08/723,504 filed on 30 September 1996. U.S. 
Application No. 08/723,504 issued as Patent No. 5,813,972, which is hereby 
incorporated by reference. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

[0002] The present invention is directed to a medical perfusion system 

adapted to handle the selective oxygenation, filtering and recirculation of blood in 
connection with various medical procedures. In particular, the present invention 
relates to controlling pumps in the perfusion system. 

2. Background Information 

[0003] The present invention is directed to a medical perfusion system 

adapted to handle the selective oxygenation, filtering and recirculation of blood in 
connection with various medical procedures. A conventional perfusion system may 
be used to oxygenate, filter, and/or recirculate the blood of a patient during a 
medical procedure. Such a perfusion system may have a fluid conduit that removes 
blood from the patient during the medical procedure, a separate fluid conduit that 
returns blood to the patient, one or more blood pumps that pump blood through 
the conduits, and a plurality of sensing devices, such as flow sensors and/or level 
sensors associated with blood pumps. The perfusion system may also include air 
embolus sensors, temperature sensors, flow occluders, etc. Typically, a perfusion 
system is provided with a configuration specifically designed to be used for a 
particular purpose. For example, one perfusion system may be specifically 
designed as a full-function heart/lung machine, while another perfusion system 



may be specifically designed as a ventricular-assist system. Although it may be 
possible to convert a perfusion system designed for one purpose to a perfusion 
system usable for a different purpose, such reconfiguration is generally difficult a 
nd/or time-consuming. In addition, perfusion systems often require a perfusionist 
operating the perfusion system to closely monitor many different parameters, and 
manually adjust the speeds of the various pumps in the system on a frequent basis 
to keep the various parameters in balance and within safe and desired limits. 
Accordingly, mechanisms are needed to help the perfusionist control the perfusion 
system with greater safety, accuracy and speed. 

SUMMARY OF THE INVENTION 
[0004] Automated fluid pump control modes in a medical perfusion system 

that help the perfusionist control the perfusion system include a Back Off 
Response Mode, a Flow Servo Mode, a Pressure Servo Mode, and a Master-Slave 
Servo Mode. In the Back Off Response Mode, pump's speed is decremented to a 
new speed when an excessive flow rate or pressure condition is detected. The new 
speed is maintained until an additional decrement is required or until the Back Off 
Response Mode is exited. In the Flow Servo Mode, a pump's speed is controlled 
to maintain a fluid flow rate indicated by a user as a setpoint. In the Pressure 
Servo Mode, a pump's speed is controlled to maintain a pressure indicated by the 
user as a setpoint. In the Master-Slave Servo Mode, a slave pump receives an 
indication of a master pump's speed, and the slave pump speed is controlled to 
maintain a specified percentage of the master pump's speed. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0005] Other objects and advantages of the present invention will become 

apparent to those skilled in the art from the following detailed description of 
preferred embodiments, when read in conjunction with the accompanying 
drawings wherein like elements have been designated with like reference numerals 
and wherein: 



[0006] FIG. 1 is a block diagram of a preferred embodiment of a perfusion 

system in accordance with the invention. 

[0007] FIG. 2 is a perspective view of the main controller shown 

schematically in FIG. 1. 

[0008] FIG. 3 is a perspective view of one of the network extenders shown 

schematically in FIG. 1. 

[0009] FIG. 4 is a perspective view of one of the adapter pods shown 

schematically in FIG. 1. 

[0010] FIGS. 5-7 illustrate a number of connector configurations. 

[0011] FIG. 8 is a perspective view of the main controller shown 

schematically in FIG. 1 with two network extenders and eight adapter pods 
plugged therein. 

[0012] FIG. 9 is a block diagram of the main controller shown 

schematically in FIG. 1. 

[0013] FIG. 10 is a block diagram of one of the extender controllers shown 

schematically in FIG. 1. 

[0014] FIG. 11 is a block diagram of one of the node controllers shown 

schematically in FIG. 1. 

[0015] FIG. 12 is a block diagram of one of the adapter pods shown 

schematically in FIG. 1. 

[0016] FIGS. 13A-13H are flowcharts illustrating the operation of the main 

controller shown in FIG. 1. 

[0017] FIGS. 14A-14B are exemplary illustrations of a pair of perfusion 

circuit images generated on the display device of FIG. 9 during operation of the 
perfusion system. 

[0018] FIGS. 15A-15C are flowcharts illustrating the operation of the 

extender controllers shown in FIG. 1. 

[0019] FIGS. 16A-16B are flowcharts illustrating the operation of the node 

controllers shown in FIG. 1. 



[0020] FIGS. 17A-17D are flowcharts illustrating the operation of the 

adapter pods shown in FIG. 1. 

[0021] FIG. 18 shows a configuration in accordance with exemplary 

embodiments of the invention. 

[0022] FIG. 19 is a flowchart illustrating back off behavior in accordance 

with an exemplary embodiment of the invention. 

[0023] FIG. 20 is a flowchart illustrating flow control in accordance with 

an exemplary embodiment of the invention. 

[0024] FIG. 21 is a flowchart illustrating pressure control in accordance 

with an exemplary embodiment of the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
[0025] FIG. 1 illustrates a preferred embodiment of a medical perfusion 

system 10 in accordance with the invention. The perfusion system 10 is adapted to 
handle the selective oxygenation, filtering and recirculation of blood in connection 
with a number of different medical procedures. The perfusion system 10 may be 
placed in a number of different configurations, each of which corresponds to a 
different medical procedure. For example, the perfusion system 10 may be 
configured as a full-function heart/lung machine, a ventricular assist system, or a 
single-pump system that can be used for various purposes, such as to perform 
blood aspiration or myocardial protection during surgery. 
[0026] Referring to FIG. 1, the main controller 20 is connected to a 

network extender 22a via a data/power bus 30a and to a network extender 22b via 
a data/power bus 30b. The network extender 22a includes an extender controller 
32a connected to three node controllers 34a, 34b, 34c via a data/power bus 30c. 
The node controller 34a is connected via a data/power bus 30d to an adapter pod 
40a, which is in turn connected to a perfusion device 50 in the form of a flow 
sensor 50a via a bidirectional data/power line 52a. The node controller 34b is 
connected via a data/power bus 30e to an adapter pod 40b, which is connected to 
an air embolus sensor 50b via a bidirectional line 52b. The node controller 34c is 



connected via a data/power bus 30f to an adapter pod 40c, which is connected to a 
blood pump 50c via a bidirectional line 52c. 

[0027] The network extender 22b includes an extender controller 32b 

connected to three node controllers 34d, 34e, 34f via a data/power bus 30g. The 
node controller 34d is connected via a data/power bus 30h to an adapter pod 40d, 
which is connected to a pressure sensor 50d via a bidirectional line 52d. The node 
controller 34e is connected via a data/power bus 30i to an adapter pod 40e, which 
is connected to a temperature sensor 50e via a bidirectional line 52e. The node 
controller 34f is connected via a data/power bus 30j to an adapter pod 40f, which 
is connected to a flow occluder 50f via a bidirectional line 52f . 
[0028] The main controller 20 is operatively coupled to a blood pump 50g 

via a bidirectional line 52g connected to an adapter pod 40g. The pod 40g is 
connected to the main controller 20 via a data/power bus 30k. The main controller 
20 is operatively coupled to a level sensor 50h via a bidirectional line 52h 
connected to an adapter pod 40h, which is connected to the main controller 20 via 
a data/power bus 301 . 

[0029] As used herein, the term "perfusion device" is a device designed to 

be used in a medical perfusion system, including but not limited to a blood pump 
such as a centrifugal or roller pump, a flow sensor, a pressure sensor, a 
temperature sensor, a level sensor, an air embolus sensor or an occluder. 

Mechanical Structure of Network Components 
[0030] FIG. 2 is a perspective view of a portion of one mechanical 

embodiment of the main controller 20. Referring to FIG. 2, the main controller 20 
has four network connectors 60, which are shown schematically. Each of the 
network connectors 60 is identical and has the same connector configuration. FIG. 
5 illustrates the structure of the connectors 60. As shown in FIG. 5, each 
connector 60 may be, for example, a standard personal computer connector having 
nine conductive pins 62 partially surrounded by an asymmetrical metal housing 
64. 



[0031] FIG. 3 is a perspective view of one embodiment of the network 

extenders 22 shown schematically in FIG. 1. Each network extender 22 has a 
hexahedral housing 66 with one side 68 on which three connectors 70 are disposed 
and an opposite side on which a connector 72 is disposed. Each connector 70 is 
identical to the connectors 60 and has the structure shown in FIG. 5. The 
connector 72, which is shown in FIG. 6, has nine pin receptacles 74 formed in an 
asymmetrical housing 76 composed of an insulating material such as plastic. The 
pin receptacles 74 are located to correspond to the positions of the nine pins 62 of 
the connector 60. Consequently, the connector 72 has the same connector 
configuration as the connector 60 and thus can be plugged into the connector 60. 
[0032] FIG. 4 is a perspective view of the adapter pods 40 shown 

schematically in FIG. 1. Referring to FIG. 4, each adapter pod 40 has a 
hexahedral housing with one side 82 on which a connector 84 is disposed and an 
opposite side on which a connector 86 is disposed. The connector 86 is identical to 
the connectors 72 described above (and shown in FIG. 6). The connector 84 is 
adapted to be connected to a device connector (not shown) that is associated with 
one of the perfusion devices 50 described above. The connector 84 has a different 
connector configuration than the connectors 60, 70, 72, 86. One example of the 
structure of the connector 84 is shown in FIG. 7 to include six conductive pins 88. 
Since each of the adapter pods 40 is adapted to be connected to a different type of 
perfusion device 50 (the pumps 50c, 50g may be different types of pumps, such as 
a roller pump or a centrifugal pump), the connector 84 disposed on each of the 
adapter pods 40 may have a different connector configuration. 
[0033] Since the connectors 60 of the main controller 20 and the 

connectors 70 of the network extenders 22 have the same connector configuration 
as the connector 86 of the adapter pods 40, it should be noted that any of the 
adapter pods 40 may be plugged into any of the connectors 60, 70. As a result, 
any combination of perfusion devices 50 may be connected to the main controller 
20. 



[0034] FIG. 8 illustrates the main controller 20 having the network 

extenders 22 and the adapter pods 40 connected to it. Each of the adapter pods 40 
of FIG. 8 would be connected to a respective one of the perfusion devices 50 
shown in FIG. 1 via a respective connector (not shown) attached to the perfusion 
device 50 by a cable. 

[0035] Although the form of the network extenders 22 shown in FIGS. 3 

and 8 makes the resulting control unit compact, network extenders having 
different structures could be used. For example, instead of having the connector 
72 fixed on the housing 66, the connector 72 could be connected to the housing 66 
via a cable. Alternatively, the housing 66 could be eliminated, and the connectors 
70, 72 could be interconnected via cables. 

Electronics 

[0036] FIG. 9 is a block diagram of the main controller 20 shown 

schematically in FIG. 1. Referring to FIG. 9, the main controller 20 has a 
microprocessor (MP) 100, a random-access memory (RAM) 102, a nonvolatile 
memory 104 such as a hard disk or a flash RAM, a network controller 106, a 
drawin controller 108, and an input/output (I/O) circuit 110, all of which are 
interconnected by an address/data bus 112. The I/O circuit 110 is connected to a 
display device 114, such as a CRT or a flat-panel display, and an input device 
116, such as a keyboard or electronic mouse or a touch screen on the display 
device 114. 

[0037] The main controller 20 also includes a power supply circuit 118 

that is connected to an outside source of AC power and which includes an internal 
transformer (not shown) that generates +5 volt and +24 volt DC power on a pair 
of electrical power lines relative to a ground line, which lines are schematically 
designated 120 in FIG. 9. The electrical power and ground lines 120 are provided 
to each of four node controllers 34g-34j via a data/power bus 30m and to the other 
node controllers 34 via the other portions of the network bus 30. The data/power 
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bus 30m includes a number of data communication lines which are connected to 
the network controller 106. 

[0038] FIG. 10 is a block diagram of the extender controller 32a shown 

schematically in FIG. 1 (the design of the extender controllers 32a, 32b is the 
5 same). Referring to FIG. 10, the extender controller 32a has a controller 130 and 
a switch 132, both of which are connected to the data/power bus 30a. The 
p extender controller 32a is connected to its parent node controller 34g via a 

S bidirectional signal line 133. As used herein, a "parent" device is a connected 

5 device that is closer to the network controller 106 (FIG. 9) of the main controller 

s==a 

%0 10 20 The node controller 34g transmits a unique physical address to the extender 

m 

controller 32a via the line 133, and the extender controller 32a includes a driver 
j3 circuit 135 which is used to periodically transmit a check-in code to the node 

controller 34g via the line 133. The check-in code and the physical address may be 
the same binary code. 

^ 15 [0039] FIG. 11 illustrates a block diagram of the node controller 34a 

shown schematically in FIG. 1 (the design of all the node controllers 34 is the 
same). Referring to FIG. 11, the node controller 34a has a controller 140 which 
receives an enable signal or a disable signal from the extender controller 32a via 
one of the lines 134 and a periodic check-in code from the adapter pod 40a via the 
20 line 133. The controller 140 is connected to a code generator 144 via a 

multi-signal line 146. The code generator 144 generates a predetermined multi-bit 
binary code that uniquely specifies the physical address of the node controller 34a. 
The code generator 144 may be, for example, a number of printed metal circuit 
lines, one line for each bit of the code, each line being selectively connected either 
25 to +5 volts (logic "1") or to ground (logic "0"). 

[0040] The controller 140 selectively operates a switch 150 that either 

connects or disconnects a data bus 152, which may be composed of two individual 
data lines, that is part of the data/power buses 30c, 30d (and the other buses 30 
that make up the network). When the switch 150 is open, the data buses 30c, 30d 



are disconnected, and when the switch 150 is closed, the buses 30c, 30d are 
connected to enable data communications between the adapter pod 40a and the 
other devices connected to the network 30. 

[0041] The controller 140 also operates a switch 154 that controls whether 

+24 volt DC power (relative to a ground line 120c) on a electrical power line 
120a is supplied to the adapter pod 40a and a switch 158 that controls whether +5 
volt DC power on an electrical power line 120b is supplied to the adapter pod 40a. 
The electrical power lines 120a, 120b are part of the data/power buses 30c, 30d 
and the other buses 30 that make up the network. A resistor 162 is connected in 
parallel with the switch 154, and a resistor 164 is connected in parallel with the 
switch 158. The resistors 162, 164 act as current-limiting resistors which prevent 
large amounts of current from being drawn from the power lines 120a, 120b when 
the switches 154, 158 are open. The controller 140 is connected to a driver circuit 
170 which is used to transmit the physical address generated by the code generator 
144 to the adapter pod 40a via the line 133. 

[0042] FIG. 12 illustrates a block diagram of the adapter pod 40a shown 

schematically in FIG. 1. Referring to FIG. 12, the adapter pod 40a has a 
controller 180 which is powered by a power supply 182 connected to the electrical 
power lines 120a, 120b. The controller 180 may transmit a check-in code on the 
line 133 via a driver 184. The controller 180 receives network messages from the 
data bus 152 and transmits messages onto the data bus 152 via a transceiver 186. 
[0043] The controller 180 is connected to a memory 188 and to a device 

interface circuit 190. The device interface circuit 190 has a plurality of data lines 
192 and a plurality of electrical power lines 194 which are connected to the 
perfusion device 50a via the connector 84 (FIG. 7). The controller 180 causes 
various types of data signals to be transmitted to the perfusion device 50a via the 
data lines 192. 

[0044] Depending on the type of perfusion device 50 to which an adapter 

pod 40 is connected, the signals on the data lines 192 might include, for example, 
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digital or analog signals (e.g. 4-20 ma signals) relating to the control of the 
perfusion device 50, such as a desired pump speed or mode of operation. The 
number of data lines 192 used depends on the particular perfusion device 50 to 
which the adapter pod 40 is connected. 

[0045] The controller 180 also causes various types of electrical power to 

be transmitted to the perfusion device 50 via the power lines 194. These types of 
power include, for example, +5 volt DC power or +24 volt DC power. If power 
of another voltage level is necessary, the power supply circuit 182 may comprise a 
DC/DC converter. 

Configuration and Display of Perfusion Circuit 
[0046] ' Prior to using the perfusion system 10 for a medical procedure, the 
operator connects the desired perfusion devices 50 to the main controller 20 by 
physically connecting the desired adapter pods 40 and/or network extenders 22 to 
the main controller 20, as shown in FIG. 8. 

[0047] Prior to the commencement of a medical procedure, the perfusion 

system 10 is configured during a configuration process illustrated in FIG. 13A, 
which is a flowchart of a configuration computer program routine 200 executed by 
the main controller 20. Referring to FIG. 13A, at step 202 the program generates 
a visual prompt to the operator to request whether a previous configuration file 
should be loaded from the memory 104 of the main controller 20. A configuration 
file generally includes image data corresponding to an image of a perfusion 
circuit, which may include an outline of the patient, images of a plurality of fluid 
conduits connected to the patient, and images of the various perfusion devices 50 
used in the system 10. Each perfusion device 50 may be represented by a different 
image, depending upon the type of perfusion device. For example, pumps may be 
represented by a pump image, whereas a flow sensor may have a different image. 
[0048] The configuration file may also include data relating to the 

perfusion devices 50, such as the manufacturer and model number of the device, 
the desired operational mode of the device, numeric limits at which an alarm 



should be triggered, and identification of any associated perfusion device. Two 
perfusion devices may be "associated" if one device that is used to control a 
physical process, referred to herein as a control device, is to receive feedback 
from another perfusion device, referred to herein as a sensing device. 
[0049] For example, referring to FIG. 1, the pump 50g could be controlled 

based on feedback generated by either the level sensor 50h (which would generate 
a signal indicative of fluid level within a fluid reservoir) or the flow sensor 50a. In 
the former case, the pump 50g could be controlled to maintain a predetermined 
level of fluid within the reservoir, and in the latter case the pump 50g could be 
controlled to maintain a predetermined flow through the conduit. Any type of 
conventional feedback control could be used, such as proportional-integral (PI) or 
proportional-integral-derivative (PID) control. Where it is desired to control the 
pump 50g based on the output of the level sensor 50h, the association of the pump 
50g with the level sensor 50h would be stored in the configuration file. 
[0050] Referring to FIG. 13 A, if the operator requested the loading of a 

configuration file at step 202, the program branches to step 204 where the 
operator is prompted to select one of those configuration files. If the operator did 
not want to retrieve a previously stored configuration file, the program branches 
to step 206, where the operator selects one of a predetermined number of types of 
perfusion circuit images. Each perfusion circuit image could correspond to the 
perfusion circuit that would be utilized for a different medical procedure. Two 
different types of perfusion circuit images are illustrated in FIGS. 14A, 14B 
described below. 

[0051] At step 208, either the perfusion circuit image corresponding to the 

configuration file selected at step 204 or the perfusion circuit image selected at 
step 206 is displayed on the display 114. A pair of exemplary perfusion circuit 
images that may be displayed on the display 114 are illustrated in FIGS. 14 A and 
14B. 
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[0052] Referring to FIG. 14A, an image 232 of a perfusion circuit 

corresponding to a left ventricle assist device (LVAD) configuration is shown. 
The perfusion circuit image 232 includes a patient image 234, an image 236 of a 
fluid conduit which removes blood from the left ventricle of the patient, an image 
238 of a pump, an image 240 of a fluid conduit which returns blood to the aorta of 
the patient, an image 242 of a flow occluder, an image 244 of a temperature 
sensor, and a pair of images 246 of an air embolus sensor. 
[0053] Referring to FIG. 14B, an image 248 of a perfusion circuit 

corresponding to a bi-ventricular assist device (Bi-VAD) configuration is shown. 
The perfusion circuit image 248 includes all of the images shown in FIG. 14A, as 
well as an image 250 of a second blood pump, an image 252 of a conduit which 
removes blood from right ventricle of the patient, and an image 254 of a conduit 
that returns blood to the pulmonary artery of the patient. Each of the perfusion 
circuit images illustrated in FIGS. 14A, 14B could be pre-stored in the memory 
104 of the main controller 20, in addition to other types of perfusion circuit 
images. 

[0054] At step 210, the operator may select one of a number of 

configuration options to change the configuration of the perfusion system 10. If 
the operator selects the option of adding a perfusion device 50 as determined at 
step 212, the program branches to step 214 where the operator is prompted to 
select a type of perfusion device 50, such as a pump or a flow sensor, to add to 
the perfusion circuit image displayed on the display 114. At step 216, the operator 
selects the position at which an image of the newly selected perfusion device 50 
will be displayed. This position could be specified by the operator via an 
electronic mouse, and the displayed perfusion circuit image could include a 
number of possible connection points 256 (FIG. 14A) at which the perfusion 
device 50 could be connected. The possible connection points 256 could be 
highlighted, such as by placing them in a bold color or making them blink on and 
off, so that the possible connection points 256 are readily apparent to the operator. 
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After the operator selects the position, at step 218, an image of the perfusion 
device is displayed in the perfusion circuit image at that position. 
[0055] If the operator selected the option of configuring one of the 

perfusion devices as determined at step 220, the program branches to step 222 
where the current configuration of the perfusion device 50 is displayed next to the 
image of the device in the perfusion circuit. As noted above, the current 
configuration could include the mode of operation of the perfusion device, alarm 
limits for the device, any associated perfusion devices, etc. At step 224, the 
operator may change or add to the current configuration. 
[0056] If the operator selected the option of displaying data for the 

perfusion devices as determined at step 226, the program branches to step 228 
where it checks to determine whether there is data available to display. Such data 
could include, for example, the manufacturers and model numbers of the perfusion 
devices. If there is data available as determined at step 228, the program branches 
to step 230 where the data is displayed next to the perfusion devices in the 
perfusion circuit. 

Connecting Perfusion Devices 
[0057] The main controller 20 may utilize a plug-in procedure to 

accommodate perfusion devices 50 that are subsequently connected to the 
perfusion system 10. FIG. 13B is a flowchart of a plug-in routine 260 performed 
by the main controller 20. During the plug-in routine, the main controller 20 may 
operate in an automatic match mode in which it can match a previously entered 
device configuration with a perfusion device that is subsequently connected to the 
main controller 20. For example, a operator may configure a centrifugal blood 
pump (not yet connected to the main controller 20) to operate in a continuous 
mode to continuously pump a predetermined flow. When the blood pump is 
subsequently connected to the controller 20, the controller 20 will then 
automatically match the previously stored pump configuration with the pump. 
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[0058] Referring to FIG. 13B, at step 262, if the main controller 20 is in 

the automatic match mode, the program branches to step 264 where it determines 
whether there is only one possible match between the perfusion device just 
connected and the previously stored device configurations. This would be the case 
where there is only one previously stored configuration for a pump and where the 
device that was just connected to the main controller 20 was a pump. 
[0059] If there was only one possible match as determined at step 264, the 

program branches to step 266 where it determines whether the position at which 
the device is to be displayed in the perfusion circuit image is known. This position 
could be included in the previously stored configuration for the device. If the 
position is not known, the program branches to step 268 where the operator is 
prompted to select a position, and then the program branches to step 270 where an 
image of the newly connected perfusion device is displayed in the perfusion circuit 
image. If the position of the device as determined at step 266 was known, the 
program skips step 268 and branches directly to step 270. 

[0060] If the main controller 20 was not in the automatic match mode, as 

determined at step 262, or if there was more than one possible match, as 
determined at step 264, the program branches to step 272. If the newly connected 
device has already been configured, the program branches to step 274 where the 
operator is prompted to select the proper configuration from a plurality of 
prestored configurations. If the device is not already configured, the program 
branches to step 276 where the operator enters the desired configuration 
parameters for the device. The program then performs steps 268 and 270 
described above. 

Network Communications 
[0061] The network controller 106 (FIG. 2) in the main controller 20, 

which may be a conventional network controller such as a CAN Version 2. 0B, 
oversees the data flow on the network buses 30, each of which includes the data 
bus 152 (which may be composed of two wires) on which digital data packets are 
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transmitted and received. The data packets may have a conventional format 
composed of the following data fields: 1) a start-of-frame (SOF) field; 2) an 
arbitration field; 3) a control field; 4) a variable-length data field; 5) an error 
detection/correction field, such as a cyclic-redundancy-check (CRC) field; 6) an 
acknowledgement (ACK) field; and 7) an end-of-frame (EOF) field. 
[0062] The arbitration field, which may be a 29-bit field, is used to 

determine the priority of the data packets broadcast over the network bus 30. The 
priority is based on the overall numeric value of the arbitration field of the data 
packets. In the event of a conflict in the transmission of two data packets, the data 
packet having the arbitration field with a lower numeric value takes priority. The 
arbitration fields, which contain a message identification (ID) code specifying the 
type of message, of a number of different data packet types that may be used are 
listed below. 



Type Message ID (MSB to LSB) 



A 


00000 


00000000 


cccccccc 


cccccccc 


B 


00000 


00000001 


cccccccc 


cccccccc 


C 


00000 


00000010 


aaaaaaaa 


ssssssss 


D 


00000 


00000100 


cccccccc 


ssssssss 


E 


00001 


cccccccc 


cccccccc 


dddddddd 


F 


00010 


cccccccc 


cccccccc 


ssssssss 


G 


10000 


cccccccc 


dddddddd 


dddddddd 


H 


10001 


cccccccc 


ssssssss 


ssssssss 


I 


11111 


11111111 


11111111 


11111111 
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[0063] In the above table, the message types are listed from highest 

priority (at the top) to lowest priority (at the bottom). 

[0064] The type A message corresponds to a control message broadcast by 

the main controller 20 to all devices attached to the network data buses. The data 
fields "cccccccc cccccccc" are used to specify the type of message. 
[0065] The type B message corresponds to a message broadcast by the 

main controller 20 to the extender controllers 32. The data fields "cccccccc 
cccccccc" are used to specify the type of message. 

[0066] The type C message corresponds to an alarm or safety message, 

with the data field "aaaaaaaa" specifying an alarm type and the data field 
"ssssssss" specifying the logical address of the device which generated the alarm 
message. 

[0067] The type D message corresponds to a servo message generated by a 

sensing device, such as a flow sensor. The data field "cccccccc" specifies the type 
of sensed parameter, e.g. flow, and the data field "ssssssss" specifies the logical 
address of the sensor that generated the sensed parameter. 

[0068] The type E message corresponds to a general message having a data 

field "cccccccc cccccccc" which specifies the type of message and a data field 
"dddddddd" which specifies the logical address of the intended destination of the 
message. 

[0069] The type F message corresponds to a general message having a data 

field "cccccccc cccccccc" which specifies the type of message and a data field 
"ssssssss" which specifies the logical address of the source of the message. 
[0070] The type G message corresponds to a general message having a data 

field "cccccccc" which specifies the type of message and a data field "dddddddd 
dddddddd" which specifies the physical address of the intended destination of the 
message. 
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[0071] The type H message corresponds to a general message having a data 

field "cccccccc" which specifies the type of message and a data field "ssssssss 
ssssssss" which specifies the physical address of the source of the message. 
[0072] The type I message (which is all logical "l"s) corresponds to a 

status request from the main controller 20 that is periodically broadcast to all 
devices connected to the network data buses. 

[0073] Some of the message types described above are transmitted without 

any data fields. For example, the status request message from the main controller 
20 would not have a data field. Other messages would include data fields. For 
example, the servo message (type D above) would include a data field which 
specified the numeric value of the sensed condition, such as a flow reading of 
0.257 liters per minute. 

[0074] The main controller 20, the extender controllers 32, and the adapter 

pods 40 may include conventional electronics for checking the accuracy of 
received messages via the CRC field, requesting retransmission of messages that 
were not accurately received, and for transmitting acknowledgement messages in 
response to the receipt of accurately received messages. 

[0075] The messages described above may be transmitted or broadcast to 

all the devices connected to the network 30. Each device, such as a pod 40 or an 
extender controller 32, can discriminate by receiving only certain messages that 
are broadcast. For example, this discrimination could be accomplished by 
accessing a message-discrimination memory in the receiving device which stores 
the logical addresses of all the other devices in which the receiving device is 
interested. 

[0076] For example, if the receiving device is the adapter pod 40c 

connected to the blood pump 50c which controls the flow of blood through a 
conduit based on receiving a feedback signal from the flow sensor 50a, the 
message-discrimination memory of the pod 40c would include the logical address 
of the flow sensor 50a, so that the pod 40c would receive any message generated 
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by the pod 40a connected to the flow sensor 50a. The message-discrimination 
memory would include logical address of the main controller 20, and could 
include the logical addresses of a number of other pods 40. Consequently, it 
should be noted that it is not necessary that messages broadcast over the network 
30 include a specific destination address (although a destination address may be 
included). 

[0077] The pods 40 and extender controllers 32 could also discriminate 

messages based on the type of message instead of the identity of the sender. For 
example, a pod 40 could receive all status-request messages and configuration 
messages (described below). The message identification codes for such messages 
could also be stored in the message-discrimination memory. 

[0078] Before use of the perfusion system 10 for a medical procedure, and 

after all the perfusion devices 50 are configured as described above, data packets 
containing configuration messages are transmitted to all the pods 40 connected to 
the network 30. The configuration messages include all the necessary 
configuration data described above. For example, for a blood pump, the 
configuration data would include the operational mode of the pump, the desired 
flow rate of the pump, etc. If any configuration messages which include device 
association data (e.g. the sensor which a blood pump should receive feedback 
from) were received by a pod 40, the message-discrimination memory would be 
updated with the logical address of the associated device. 

Connecting Pods to the Network 
[0079] In order for them to communicate with the main controller 20 via 

the network data/power buses 30, the adapter pods 40 must be granted permission 
to connect to the network 30. This connection is initiated with a startup-request 
message transmitted to the main controller 20 by the adapter pod 40 for which the 
network connection is to be made. The startup-request message includes a first 
code identifying the type of perfusion device 50 connected to the pod 40 
requesting to be connected and a second code identifying the physical address 
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(specified by the code generator 144 of FIG. 11) of the pod 40 requesting to be 
connected. 

[0080] FIG. 13C is a flowchart of a startup routine 280 that is performed 

by the main controller 20 in response to the receipt of a startup-request message 
from an adapter pod 40. The startup routine 280 may be an interrupt service 
routine which is invoked in response to an interrupt generated upon the receipt of 
a startup-request message by the main controller 20. Referring to FIG. 13C, at 
step 282, the startup message received by the main controller 20 is decoded to 
determine the type of the perfusion device 50 attached to the pod 40 requesting to 
be connected and to determine the physical address of the pod 40. 
[0081] At step 284, the program determines whether full power should be 

granted to the requesting pod 40. As described above, electrical power to run the 
perfusion devices 50 is provided to the pods 40 via the network 30 from a power 
supply 118 (FIG. 9) in the main controller 20. Since the power available from the 
power supply 118 may be limited, the main controller 20 may be programmed to 
allow only a certain number of perfusion devices 50 to be connected to the 
network 30, or alternatively, to allow only certain numbers of specific types of 
perfusion devices 50 to be connected. For example, since control devices such 
blood pumps typically draw more power than sensing devices, the main controller 
20 may be provided with an upper limit on the number of control devices that can 
be connected to the network 30. 

[0082] At step 284, the decision whether to grant full power could be made 

by comparing the number of perfusion devices 50 already connected to the 
network 30 with the maximum number that can be connected to determine whether 
the connection of an additional device 50 will cause the maximum to be exceeded. 
Alternatively, if the device requesting connection is a control device, then the 
number of control devices already connected could be compared with the 
maximum number of control-type perfusion devices that can be connected. If it is 
determined that full power should not be granted, the program simply ends. 
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[0083] If it is determined that full power should be granted, steps 286-298 

are performed to generate and transmit a startup granted message that will cause 
the pod 40 associated with the perfusion device 50 to be connected to the network 
30. In particular, at step 286, a unique logical address is allocated to the newly 
connected pod 40. For example, where the capacity of the network 30 is sixteen 
devices, the logical address may be a four-bit binary code. At step 288, a 
startup-granted message which includes the logical address is encoded, and at step 
290 the startup-granted message is transmitted over the network 30. At step 292, 
if the pod 40 which requested startup is local to the main controller 20 (i.e. if it is 
one of the pods 40g or 40h directly connected to the main controller 20 without a 
network extender 22), full power to the pod 40 is enabled via the local node 
controller (i.e. one of the node controllers 34i-34j of FIG. 9) connected to the 
perfusion device 50. Referring to FIG. 11, this is accomplished by sending an 
enable signal on the line 134, which will cause the controller 140 to close the 
switches 150, 154, 158 so that full power is supplied on the power lines 120a, 
120b and so that the adapter pod 40 is connected to the data bus 152. 
[0084] Referring to FIG. 13C, if the perfusion device was not a local 

device as determined at step 292, the program branches to step 296 where a 
connect message which includes the physical address of the node controller 34 
associated with the pod 40 requesting startup is encoded, and then to step 298 
where the connect message is transmitted over the network 30. As described 
below, when the extender controllers 32 receive the connect message, they decode 
it to determine the physical address, and the extender controller 32 connected to 
the node controller 34 having that physical address (i.e. the node controller 34 
associated with the requesting pod 40) turns on full power by transmitting an 
enable signal on the line 134 connected to that node controller. 

Status Requests 

[0085] During operation of the perfusion system 10, to ensure that all 

devices connected to the network 30 are properly functioning and are receiving 
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messages broadcast over the network 30, the main controller 20 periodically 
transmits a status-request message to all extender controllers 32 and adapter pods 
40 on the network 30. Each extender controller 32 and adapter pod 40 must 
respond to the status request within a predetermined period of time. Any extender 
controller 32 or pod 40 that fails to respond to the status request within that time 
period is disconnected from the network 30, and a corresponding alarm message is 
generated on the visual display 1 14 to warn the operator of such event. 
[0086] FIG. 13D is a flowchart of a status-request routine 300 periodically 

performed by the main controller 20. Referring to FIG. 13D, at step 302 a 
status-request message is encoded, and at step 304 the message is broadcast to all 
extender controllers 32 and adapter pods 40 connected to the network 30. As 
described above, the status-request message may simply be all logical "l"s in the 
arbitration of the data packet. At step 306, a predetermined time-out period within 
which all extender controllers 32 and pods 40 must respond to the status request 
message is started. 

[0087] Upon receiving the status-request message, each extender controller 

32 and adapter pod 40 encodes a status message with its logical address and its 
status, and then broadcasts the status message to the main controller 20 over the 
network 30. 

[0088] FIG. 13E is a flowchart of a receive status routine 310 that is 

performed by the main controller 20 upon receipt of a status message transmitted 
to it in response to the status-request message previously transmitted by the 
routine 300. Referring to FIG. 13E, at step 312 the logical address of the 
responding extender controller 32 or adapter pod 40 is determined from the status 
message, and at step 314 the status of the device 32 or 40 is determined from the 
message. The status may be specified by a number of different binary status 
codes. At step 316, if the status of the device 32 or 40 is okay, the program 
simply ends. However, if the status is not okay, the program branches to step 318 
where it responds to a status condition identified by the status code. If the 
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condition is relatively minor, the main controller 20 may simply generate a 
warning on the visual display 114 of the perfusion system 10. If the condition is 
serious enough, the main controller 20 may disconnect the device 32 or 40 from 
the network 30. 

[0089] FIG. 13F is a flowchart of a disconnect routine 330 that causes an 

extender controller 32 or an adapter pod 40 to be disconnected from the network 
30. The disconnect routine 330 is performed by the main controller 20 in response 
to either: 1) the failure of a device 32 or 40 to transmit a status message to the 
main controller 20 within the timeout period described above or 2) a serious 
malfunction of a device 32 or 40 as determined at step 318 of FIG. 13E. 
[0090] Referring to FIG. 13F, at step 332, if the device 32 or 40 to be 

disconnected is local to the main controller 20, the program branches to step 334 
where that device 32 or 40 is disconnected by the node controller 34g, 34h, 34i, 
or 34j in the main controller 20 that is connected to that device 32 or 40. 
Referring to FIG. 11, the disconnection is accomplished by transmitting a disable 
signal on the line 134, which will cause the controller 140 to open the switches 
150, 154, 158 so that the data bus 152 and the power lines 120a, 120b are 
disconnected. 

[0091] At step 332, if the device to be disconnected is not local to the main 

controller 20, the program branches to step 336 where a disconnect message 
which includes the physical address of the node controller 34 of the device 32 or 
40 to be disconnected is encoded, and then to step 338 where the disconnect 
message is transmitted over the network 30. 

[0092] If the device to be disconnected is a pod 40 connected to an 

extender controller 32 via a node controller 34, when that extender controller 32 
receives the disconnect message, it decodes it to determine the physical address of 
the pod 40 to be disconnected, and the node controller 34 associated with that pod 
40 disconnects the pod 40 by transmitting a disable signal on the line 134 
connected to that node controller 34. 



-23- 

Operator Commands Input to Main Controller 
[0093] During operation of the perfusion system 10 during a medical 

procedure, the main controller 20 responds to various commands and other inputs 
entered by the operator of the system 10. FIG. 13G is a flowchart of a control 
command routine 350 which illustrates how the main controller 20 responds to 
those inputs. While FIG. 13G discloses various possible operator inputs, it should 
be understood that the main controller 20 could respond to other or additional 
operator inputs. 

[0094] Referring to FIG. 13G, at step 352, if the input entered by the 

operator was a control command, the program branches to step 354 where a 
control message corresponding to the control command is encoded in a data 
packet, and then to step 356 where the control message is broadcast over the 
network 30. For example, the control message could be one of the following: 1) a 
new alarm limit for a particular sensing device; 2) a new mode of operation for a 
blood pump; 3) a new target flow value for a blood pump; 4) a new rate at which 
a particular sensing device should be read; 5) a pump start command; 6) a pump 
stop command; etc. 

[0095] At step 358, if the operator requests that a particular alarm be reset, 

the program branches to step 360 where a corresponding alarm-reset message, 
which includes the logical address of the device that generated the alarm, is 
encoded and to step 362 where the alarm-reset message is broadcast over the 
network 30. At step 364, if the operator requests that the perfusion system 10 be 
reset, the program branches to step 366 where a corresponding system reset 
message is encoded and to step 362 where the system reset message is broadcast 
over the network 30. 

Receipt of Network Messages by Main Controller 
[0096] During operation, the main controller 20 receives messages of 

various types that are broadcast over the network 30. FIG. 13H is a flowchart of a 
receive routine 370 performed by the main controller 20 that illustrates actions 
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taken by the main controller 20 in response to the receipt of various types of 
messages. 

[0097] Referring to FIG. 13H, at step 372, if the received message 

corresponds to an event message, such as an alarm or other event, the program 
branches to step 374 where the visual display generated on the display device 1 14 
is updated to advise the operator of that event, and the program branches to step 
376 where the event is logged into an event log stored in the memory 104 of the 
main controller 20. 

[0098] At step 378, if the received message corresponds to a data message, 

such as a message which includes the numeric value representing the output of a 
flow sensor, the program branches to step 380 where the visual display is updated, 
and the program branches to step 382 where the data and the device which 
generated the data are logged into a data log stored in the memory 104 of the main 
controller 20. 

[0099] At step 384, if the received message is a status message, the 

program branches to step 386 where the status message is processed, as described 
above in connection with FIG. 13E. At step 388, the visual display is updated 
based on the status, and at step 390 the status is stored in a status log stored in 
memory. At step 392, if the received message is a startup request, the program 
branches to step 394 where the startup request is processed, as described above in 
connection with FIG. 13C, and at step 396, the visual display is updated. 

Operation of Extender Controllers 
[00100] A basic function of the extender controllers 32 is to control 

the connection and disconnection of adapter pods 40 to the network 30. FIG. 15A 
is a flowchart of a startup routine 420 performed by the controller 130 of each 
extender controller 32. Referring to FIG. 15A, at step 422 the extender controller 
32 performs a number of internal self-tests, such as tests of an internal RAM and 
an internal ROM. At step 424, if the tests were successful, the program branches 
to step 426 where the connection of the extender controller 32 to the network bus 
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30 is tested by transmitting a message onto the network bus 30 and simultaneously 
receiving the message from the network bus 30 as it is transmitted to determine if 
the message was in fact transmitted. 

[00101] At step 428, if the data bus test was successful, the program 

branches to step 430 where the extender controller 32 starts to periodically 
transmit a check-in code to its parent node controller 34 via the line 133. As 
described below, each device (either an adapter pod 40 or an extender controller 
32) must periodically transmit a check-in code to its parent node controller 34 to 
maintain its connection to the network 30. 

[00102] At step 432, the extender controller 32 waits for its physical 

address to be transmitted to it from its parent node controller 34. At step 434, if 
not all of the tests performed at steps 422 and 426 were passed, an error message 
is broadcast over the network 30. The error message includes the physical address 
of the extender controller 32 and a binary code which specifies which test(s) were 
not passed. 

[00103] If all tests were passed, the program branches to step 438 

where a startup-request message containing the physical address of the extender 
controller 32 is encoded and broadcast over the network 30. At step 440, the 
program waits until a startup-granted message is received from the main controller 
20, and then at step 442 the program waits until full power is granted to the 
extender controller 32 via the electrical power lines 120a, 120b of its parent node 
controller 34. When full power is granted, the program branches to step 444 
where the extender controller 32 measures the voltages on and the current 
provided by the electrical power lines 120a, 120b to make sure they are within 
specification. At step 446, if the power measurements are not within specification, 
the program branches to step 436 where a message to that effect is broadcast to 
the main controller 20 over the network 30. 

[00104] FIG. 15B is a flowchart of a connect routine 450 performed by an 

extender controller 32 when it receives a connect message from the main 
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controller 20. Referring to FIG. 15B, at step 452, the connect message received 
from the main controller 20 is decoded to determine the physical address of the 
adapter pod 40 to be connected to the network 30. At step 454, the physical 
address is inspected to determine if the adapter pod 40 to be connected is local to 
the extender controller 32, meaning that the adapter pod 40 is one of the three that 
are connected to the extender controller 32. If the pod 40 is not local to the 
extender controller 32, no further action is taken and the routine 450 ends. If the 
pod 40 is local to the extender controller 32, the program branches to step 456 
where an enable signal is transmitted via one of the lines 134 to the node 
controller 34 associated with the adapter pod 40 to be connected, which causes the 
adapter pod 40 to be connected to the network 30 in the manner described above. 
[00105] When an extender controller 32 receives a disconnect message from 

the main controller 20, a disconnect routine 460 shown in FIG. 15C is performed 
by the extender controller 32. Referring to FIG. 15C, at step 462, the disconnect 
message received from the main controller 20 is decoded to determine the physical 
address of the adapter pod 40 to be disconnected to the network 30. At step 464, 
the physical address is inspected to determine if the adapter pod 40 to be 
disconnected is local to the extender controller 32. If the pod 40 is not local, no 
further action is taken. If the pod 40 is local, the program branches to step 466 
where a disable signal is transmitted via one of the lines 134 to the node controller 
34 associated with the adapter pod 40 to be disconnected, which causes the adapter 
pod 40 to be disconnected to the network 30. 

Operation of Node Controllers 
[00106] The basic function of the node controllers 34 is to connect and 

disconnect the adapter pods 40 (if a node controller 34 is the parent of an adapter 
pod 40) and the extender controllers 32 (if a node controller 34 is the parent of an 
extender controller 32) from the network 30. The connection or disconnection is 
performed pursuant to an enable or disable signal received either from the main 
controller 20 or from the extender controller 32 associated with the node 
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controller 34, as described above. In addition, each node controller 34 requires its 
associated device 32 or 40 to periodically check-in. If the device 32 or 40 fails to 
check in with a proper check-in code, the node controller 34 disconnects the 
device 32 or 40 from the network 30. 

[00107] FIG. 16A is a flowchart of a node routine 470 performed by each 

of the node controllers 34. The routine 470 is performed upon the receipt by the 
node controller 34 of a check-in code received from the associated device 32 or 
40. Referring to FIG. 16A, at step 472, if the code received from the device 32 or 
40 is not valid, no further action is taken and the routine ends. The check-in code 
may be the physical address specified by the code generator 144 (FIG. 11) of the 
node controller 34. To determine whether the code is valid, the node controller 34 
may compare the received code to determine whether it matches a predetermined 
code. 

[00108] If the check-in code was valid, the program branches to step 474 

where a time-out timer is restarted. The time-out timer tracks the predetermined 
period of time within which the device 32 or 40 must transmit a valid check-in 
code. At step 476, the node controller 34 transmits the physical address generated 
by the code generator 144 to the pod 40. At step 478, the node controller 34 
connects the device 32 or 40 to the data bus 152 (FIG. 11) by sending a signal to 
the switch 150 which causes it to close (or remain closed if it was already closed). 
[00109] At step 480, if the enable signal is present on the line 134 

connected to the node controller 34, the node controller 34 supplies full power to 
the device 32 or 40 by sending signals to the switches 154, 158 (FIG. 11) to cause 
them to close (or remain closed if they were already closed). 
[00110] If the enable signal was not present as determined at step 480, the 

program branches to step 484, where the device 32 or 40 is disconnected from the 
data bus 152 by opening the switch 150 and to step 484 where the device 32 or 40 
is disconnected from the electrical power lines 120a, 120b by opening the switches 
154, 158. 
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[00111] If the device 32 or 40 fails to transmit a valid check-in code to the 

node controller 34 within the time-out period, a time-out routine 490 shown in 
FIG. 16B is performed by the node controller 34. Referring to FIG. 16B, at step 
492 the device 32 or 40 is disconnected from the data bus 152 by opening the 
switch 150, and at step 494 the device 32 or 40 is disconnected from the electrical 
power lines 120a, 120b by opening the switches 154, 158. 

Operation of Adapter Pods 
[00112] The adapter pods 40 perform a number of functions, including 

receiving configuration and control messages transmitted by the main controller 
20, receiving sensing messages containing numeric values of sensed conditions, 
such as flow, and/or transmitting sensing messages over the network 30. These 
functions are described below. 

[00113] FIG. 17A is a flowchart of a startup routine 520 performed by the 

controller 180 of each adapter pod 40. Referring to FIG. 17A, at step 522 the 
adapter pod 40 performs a number of internal self-tests, such as tests of an internal 
RAM and an internal ROM. At step 524, if the tests were successful, the program 
branches to step 526 where the connection of the pod 40 to the data bus 152 is 
tested by transmitting a message onto the data bus 152 and simultaneously 
receiving the message from the data bus 152 as it is transmitted to determine if the 
message was in fact transmitted. 

[00114] At step 528, if the data bus test was successful, the program 

branches to step 530 where the adapter pod 40 starts to periodically transmit a 
check-in code to its parent node controller 34 via the line 133. At step 532, the 
pod 40 waits for its physical address to be transmitted to it from its parent node 
controller 34. At step 534, if not all of the tests performed at steps 522 and 526 
were passed, an error message is broadcast over the network 30. The error 
message includes the physical address of the pod 40 and a binary code which 
specifies which test(s) were not passed. 
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[00115] If all tests were passed, the program branches to step 538 where a 

startup-request message containing the physical address of the adapter pod 40 is 
encoded and broadcast over the network 30. At step 540, the program waits until 
a startup-granted message is received from the main controller 20, and then at step 
542 the program waits until full power is granted to the adapter pod 40 via the 
electrical power lines 120a, 120b of its parent node controller 34. When full 
power is granted, the program branches to step 544 where the pod 40 measures 
the voltages on and the current provided by the electrical power lines 120a, 120b 
to make sure they are within specification. At step 546, if the power 
measurements are not within specification, the program branches to step 536 
where a message to that effect is broadcast to the main controller 20 over the 
network 30. 

[00116] During operation, an adapter pod 40 may receive control or 

configuration messages from the main controller 20 over the network. FIG. 17B is 
a flowchart of a receive routine 550 that is performed when the adapter pod 40 
receives a message. Referring to FIG. 17B, at step 552 the message is decoded to 
determine the control command embedded in the message, and at step 554, the 
pod 40 transmits a control signal (via one or more of the data lines 192 in FIG. 
12) to the perfusion device 50 connected to it. 

[00117] During operation, an adapter pod 40 may receive an alarm signal 

from the perfusion device 50 via one of the data lines 192. When such an alarm 
signal is received, an alarm routine 560 shown in FIG. 17C is performed by the 
pod 40. Referring to FIG. 17C, at step 562 an alarm message is encoded with the 
logical address of the perfusion device 50 that generated the alarm and the type of 
alarm, and at step 564 the alarm message is broadcast over the network 30 to the 
main controller 20. 

[00118] During operation, each adapter pod 40 connected to a perfusion 

device 50, such as a flow sensor, which generates a sensing signal periodically 
reads the numeric value of the sensing signal via one of the lines 152. The time 
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period between successive readings of the sensing signal may be specified during 
the configuration process as described above. FIG. 17D is a flowchart of a sensing 
routine 570 that is performed when it is time to read the value of the sensing 
signal. Referring to FIG. 17D, at step 572 the sensing signal is read via one of the 
data lines 152. At step 574, the numeric value of the sensing signal is encoded in a 
message along with the logical address of the perfusion device 50 which generated 
the sensing signal. At step 576, that message is then broadcast over the network 
30 to all devices connected to the network 30. 

[00119] As described above, each adapter pod 40 connected to the network 

30 may be provided with a message-discrimination circuit which is used to 
selectively receive messages from only a subset of the devices connected to the 
network 30. When the sensing message is broadcast at step 576, the only devices 
that receive it are the main controller 20 (which may receive all messages 
broadcast over the network 30) and the particular perfusion device 50 which is 
being controlled based on the value of the sensing signal encoded in the sensing 
message. 

[00120] It should be understood that the adapter pods may be provided with 

additional functionality not described above. Also, instead of having electrical 
power being distributed over the network from a single power source provided in 
the main controller 20, electrical power could be distributed from a plurality of 
power sources, for example, from one power source provided in each of the 
network extenders. 

Pump Control Modes 
[00121] In accordance with exemplary embodiments of the invention, the 

fluid pumps in the perfusion system 10 can be controlled in a variety of modes. 
FIG. 18 shows an exemplary physical configuration in which the pumps can be 
controlled in various modes. 

[00122] As shown in FIG. 18, two pumps 1866, 1868 are connected to the 

perfusion system 10 via pods 1844, 1846. The pods 1844, 1846 operate in the 
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same fashion as, or in a fashion consistent with, the adapter pods 40 described 
above. In an exemplary embodiment of the invention, the pods 1844, 1846 are 
located within the corresponding pump, and each pump and associated pod are 
capable of running in a standalone condition. The pump and its associated pod can 
run in a standalone condition when, for example, they are disconnected from the 
perfusion system 10 or when the perfusion system 10 malfunctions. FIG. 18 also 
shows pods 1840, 1842, 1848 and 1850, that respectively connect the flow sensor 
1860, pressure sensor 1862, flow sensor 1868, and pressure sensor 1870 to the 
perfusion system 10. 

[00123] In exemplary embodiments of the invention, the pods 1840, 1842, 

1848 and 1850 operate in the same fashion as, or in a fashion consistent with, the 
adapter pods 40 described above. The flow sensor 1860 and the pressure sensor 
1862 are configured to monitor the output 1874 of the pump 1864, and the flow 
sensor 1868 and the pressure sensor 1870 are arranged to monitor the output 1876 
of the pump 1866, in a fashion consistent with the various sensors 50 previously 
described. 

[00124] Those of ordinary skill will recognize that the sensor pickups can 

be located at any appropriate location, for example at locations at or within the 
patient being treated with the perfusion system 10, and/or at locations between the 
pumps and the patient. In addition, a sensor pickup can monitor a condition that a 
pump influences but is not wholly responsible for, and provide feedback for 
controlling the pump. For example, the sensor can be placed at a confluence of 
fluid lines or at a location in a patient, where the fluid pressure and/or flow at that 
location is a result of several factors (including for example other pumps and/or 
the patient's physiological behavior), and one of the factors is the pump receiving 
feedback from the sensor. 

[00125] Those of ordinary skill will also recognize that additional pumps 

and/or additional sensors of various kinds to help monitor and control the pumps, 
can also be provided, in addition to those shown in FIG. 18. For example, various 
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ones of the pods 40 and the devices 50 shown in FIG. 1. In addition, those of 
ordinary skill will recognize that the sensors and pumps and their pods can 
communicate and can be electronically configured, controlled or monitored by the 
main controller 20, using for example the network communications protocol and 
network messages described further above {e.g., using appropriate ones of the A-I 
message types). For example, the sensor pods can convey information to the pump 
pods using type C, type D, type E, or type F messages. 

[00126] The pumps 1864, 1866 can each be any of a variety of different 

kinds of pumps, including a roller pump and a centrifugal pump. Pump speeds can 
be measured by measuring the speed of the pump head and/or the speed of the 
motor driving the pump head, using for example known tachometers and known 
sensors such as Hall Effect sensors. 

[00127] In an exemplary embodiment of the invention, one or more of the 

fluid pumps is controlled in a Back Off Response Mode. FIG. 19 shows a process 
in accordance with an exemplary implementation of the Back Off Response Mode. 
As shown in step 1902 of FIG. 19, a parameter of the pump's performance, such 
as pressure or flow rate, is monitored. From step 1902, control proceeds to step 
1904, where a determination is made as to whether the measured parameter 
exceeds a critical level. If No, then control returns to step 1902. If Yes, then 
control proceeds to step 1906, where th e speed setpqi nt of the pump is reduced to 
create a new pump speed setpoint. From step 1906, control proceeds to step 1908, 
where the user is alerted to the situation. From step 1908, control returns to step 
1902. 

T00128] In an exemplary implementation, the pump 1864 is linked to the 



j flow sensor pod 1840 and the pressure sensor pod 1842. The sensor pods 1840, 
; 1842 monitor circuit parameters and alert and alarm if a particular measurement 
level is crossed. For example, the pressure sensor pod 1842 can be set to alarm 
when it detects a pressure above a critical level of 150 mm Hg. The flow sensor 
pod 1840 can be set to alarm when it detects a flow rate above a critical level of 4 
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liters per minute. The pump 1864, which can for example be a centrifugal pump 
or a roller pump, is automatically connected to the sensing pods 1840, 1842, so 
that it will receive an alarm from either of the sensing pods 1840, 1842. When the 
pump pod 1844 receives an excess pressure alarm from the pressure sensor pod 
1842, or an excess flow rate alarm from the flow rate sensor pod 1840, in 
response the pump pod 1844 reduces or "backs off" the speed of the pump 1864 
by a predetermined amount, for example 10%. 

[00129] If the sensing pod 1842 continues to detect a pressure above the 

critical level, as measured by the pressure sensor 1862, or if the sensing pod 1840 
continues to detect a flow rate above the critical level, as measured by the flow 
! sensor 1860, then the pump pod 1844 can continue to back off or reduce the speed ' 
of the pump 1864 in 10% decrements. A predetermined time period can be used 
between successive reductions, for example to allow the pump time to respond to 
a command to reduce speed, before a subsequent command is issued. In an 
exemplary embodiment, the time period can vary depending on the amount by 
I which the measured parameter exceeds the critical level. For example, if the 
1 measured pressure greatly exceeds the critical level, then it may be advantageous 
to have a smaller time period to reduce the pressure more quickly, or to have a 
larger percentage decrement. 

[00130] Also, instead of percentage decrements, the pump speed can be 

reduced by a fixed amount of revolutions per minute. In addition, instead of 
reducing the pump speed by a predetermined amount (either a fixed amount of 
rpms or a percentage of rpms), the pump speed can be reduced to a predetermined 
level. For example, when the pump 1864 is a centrifugal pump, the predetermined 
level can be a "coasting level", i.e. , a small rpm value that is sufficient to prevent 
backflow, while not causing significant forward movement of the fluid being 
^pumped. 

[00131] In an exemplary embodiment of the invention, one or more of the 

fluid pumps is controlled in a Flow Servo Mode. FIG. 20 shows an exemplary 
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process of the Flow Servo Mode. In step 2002 of FIG. 20, a user sets a flow rate 
setpoint. The user can do this, for example, by adjusting the speed of one or more 
pumps until a desired flow rate is achieved, and then indicating to the perfusion 
system 10 (or to the pump directly) that the present flow rate is now a setpoint. 
Alternatively, the user can enter a desired flow rate setpoint that is different from 
the current flow rate, and the system will adjust to achieve the desired flow rate. 
[00132] From step 2002, control proceeds to step 2004, where the pump 

speed is adjusted to achieve or maintain the flow rate at the setpoint. From step 
2004, control proceeds to step 2006, where fault conditions are checked for. If a 
fault is detected, control proceeds from step 2006 to step 2008, where the fault is 
handled appropriately. For^example^ pressure or flow rate exceeding a critical 
level can shift the pump (or_pump pod) from Flow Servo Mode to Ba c k Off 
Response Mode. Other faults can trigger other responses, some of which may 
temporarily or indefinitely suspend the Flow Servo Mode. 
[00133] If no faults are detected, then control proceeds from step 2006 to 

step 2010, where a determination is made as to whether the user has adjusted the 
pump speed. If No, then control returns to step 2004. If Yes, then control 
proceeds from step 2010 to step 2012, where the flow rate at the user's selected 
pump speed is adopted as the new flow rate setpoint. From step 2012, control 
returns to step 2004. 

[00134] In an exemplary implementation, the pump 1864 (which can be, for 

example, a centrifugal pump or a roller pump) and the associated pod 1844, utilize 
an intelligent control system to maintain the blood or fluid flow rate to fixed value 
or setpoint within a clinical fluid flow setup, for example an arterial or 
cardioplegia circuit. The pump software, contained for example in the pump pod 
1844, uses feedback from an external flow sensor such as the flow sensor 1860 via 
the pod 1840, and automatically adjusts the pump speed to maintain the fluid flow 
rate at the setpoint. The flow rate sensor 1860, flow pod 1840, pump pod 1844 
and the pump 1864 work in conjunction to set up or form the automatic control 
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system. The flow pod 1840 samples the flow rate measured by the flow sensor 
1860 at a high frequency, and filters the sampled data to remove noise. The 
filtered flow samples are sent from the flow pod 1840 via appropriate portions or 
mechanisms of the system 10 to the pump pod 1844, in real time. The_pjwnp_pod_ 
1844 uses the filtered flow samples to automatical ly adj ust the s peed of the jnimp 
1864 to mainta in the flow rate at the setpoint. In an exemplary embodiment of the 
invention, the pump pod 1844 uses a piecewise linear control system to calculate 
necessary adjustments to the pump speed to maintain the flow rate at the setpoint 
in real time. No user/operator intervention is required. 
[00135] In an exemplary embodiment of the invention, the Flow Servo 

Mode is initiated when the pump 1864 is running. The pump speed is adjusted 
until the correct speed and flow rate have been reached. At this point, the user can 
"lock in" the pump to the current configuration of speed and flow rate, so that the 
pump pod 1846 will then capture the current flow rate from the flow pod 1840 and 
use the captured flow rate as the flow rate setpoint. T he user can chan ge the 
^5 setpoint while remaining inJ he Flow Servo Mode , by changing the pump speed. 
1 This temporarily disables the Flow Servo Mode until the user finishes adjusting 
the speed, at which point the Flow Servo Mode is re-enabled. The Flow Servo 
Mode adopts the new flow rate resulting from the new pump speed, as the new 
setpoint. The user's manual adjustment of the pump speed can be detected via 
software by the pump pod, and the manual adjustment of the pump speed can be 
made for example via a manual speed control that is part of the pump. 
[00136] In a further refinement of the Flow Servo Mode control system, the 

user is alerted when the control system is unable to maintain the flow at the 
setpoint. In addition, operating parameters of the pump 1864 are bounded to 
prevent unforeseen and/or undesirable action by the pump 1864. For example, the 
control software in the pump pod 1844 can limit a maximum acceleration of the 
pump (i.e., limit a maximum rate of change of the pump speed), can limit 
maximum pump speed, and can check flow data integrity and discern anomalous 
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flow data to discern invalid flow data from the flow sensor pod 1840. In the event 
the pump pod 1844 detects invalid flow data, the control software in the pump pod 
1844 can exit the Flow Servo Mode and maintain the current speed of the pump 
1864 while alerting the user to the condition. 

[00137] Additional safety conditions can also be set up, to operate within or 

in harmony with the Flow Servo Mode. For example, the pump pod 1844 can 
move from the Flow Servo Mode into the Back Off Response Mode when either 
an excess pressure or an excess flow rate condition is detected. In exemplary 
embodiments of the invention, the mode can return from the Back Off Response 
Mode to the Flow Servo Mode, for example when the pressure or flow rate has 
stabilized at an acceptable level, with the backed-off flow rate becoming the new 
set point of the Flow Servo Mode. The user can be alerted each time operation 
shifts from one Mode to another, and can also be alerted when a Mode is 
suspended. The flow pod 1840 can also be arranged to take certain actions when it 
detects specific conditions, for example by sending an alert signal when a 
backflow condition or a low-flow condition is detected. The pump pod 1844 can 
be configured to appropriately respond to such trigger messages, for example by 
stopping or pausing the pump 1864. 

[00138] In an exemplary embodiment of the invention, one or more of the 

fluid pumps is controlled in a Pressure Servo Mode. FIG. 21 shows an exemplary 
process of the Pressure Servo Mode. In step 2102, the user sets the pressure 
setpoint. From step 2012, control proceeds to step 2104, where pump speed is 
adjusted to maintain measured pressure at the setpoint. From step 2104, control 
proceeds to step 2106, where fault conditions are checked for. If a fault is 
detected, control proceeds from step 2106 to step 2108, where the fault is handled 
appropriately. For example, pressure or flow exceeding a critical level can shift 
the pump from Pressure Servo Mode to Back Off Response Mode. Other faults 
can trigger other responses, some of which may temporarily or indefinitely 
suspend the Pressure Servo Mode. 
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[00139] If no faults are detected, then control proceeds from step 2106 to 
step 2110, where a determination is made as to whether the user has adjusted the 
pump speed. If No, then control returns to step 2104. If Yes, then control 
proceeds from step 2110 to step 2112, where the pressure at the user's selected 
pump speed is adopted as the new pressure setpoint. From step 2112, control 
returns to step 2104. 

[00140] In an exemplary implementation of the Pressure Servo Mode, the 

pump 1864 (which can be, for example, a centrifugal pump or a roller pump), and 
the associated pod 1844 utilize an intelligent control system to maintain the fluid 
pressure to the fixed value or setpoint within a clinical blood flow setup, i.e. , an 
arterial or cardioplegia circuit. The pump 1864 and pod 1844 use feedback from 
the external pressure sensor 1862 via the pressure pod 1842, to automatically 
adjust the speed of the pump 1864 to maintain the fluid pressure at the setpoint. In 
other words, the pump 1864, pod 1844, pressure sensor 1862 and pressure pod 
1842 work in conjunction to set up the automatic control system of the Pressure 
Servo Mode. The pressure pod 1842 samples the pressure signal from the pressure 
sensor 1862 at a high frequency, and filters the data to remove noise. In particular 
when the pump 1864 is a roller pump, this can be important as the mechanical 
operation of the roller pump introduces large pressure spikes into the pressure 
data. These spikes should be removed if the data are used as feedback signals to 
control the roller pump. The filtered pressure samples are sent from the pressure 
pod 1842 via the perfusion system 10 to the pump pod 1844, in real time. The 
pump pod 1844 uses the filtered pressure samples to automatically adjust the speed 
of the pump 1864 to maintain the pressure at the setpoint. In the case where the 
pump 1864 is a roller pump, the pump pod 1844 also takes into account the size of 
the tube in the pump, so that the pump pod 1844 can correctly adjust the control 
parameters to provide proper pump response for different tubing setups. For 
example, the pump pod 1844 can be configured to work with a variety of different 
pumps having different configurations, including roller pumps having different 
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tubing sizes, and knowledge of the tubing size in the particular roller pump the 
pod is connected to allows the pod to correctly control the pump. In accordance 
with an exemplary embodiment of the invention, the control software in the pump 
pod 1844 uses a piecewise linear control system to calculate adjustments to the 
pump speed to maintain the pressure at the setpoint in real time. No user 
intervention is required. 

[00141] In an exemplary embodiment of the invention, the Pressure Servo 

Mode is initiated when the pump 1864 is running. The pump speed is adjusted 
until the correct speed and flow rate have been reached. At this point, the user can 
"lock in" the pump to the current configuration of speed and flow rate, and the 
pump pod 1846 will then capture the current pressure from the pressure pod 1842 
and use the captured pressure as the pressure setpoint. The user can change the set 
point while remaining in the Pressure Servo Mode, by changing the pump speed. 
This temporarily disables the Pressure Servo Mode until the user finishes adjusting 
the speed, at which point the Pressure Servo Mode is re-enabled, with the new 
pressure resulting from the new pump speed, being adopted as the new setpoint. 
The user's manual adjustment of the pump speed can be detected via software by 
the pump pod, and the manual adjustment of the pump speed can be made for 
example via a manual speed control that is part of the pump. 
[00142] As a further refinement of the Pressure Servo Mode control system, 

the user is alerted when the control system is unable to maintain the pressure at 
the setpoint. In addition, operating parameters of the pump 1864 are bounded to 
prevent unforeseen and/or undesirable action by the pump 1864. For example, the 
control software in the pump pod 1844 can limit a maximum acceleration of the 
pump (i.e. , limit a maximum rate of change of the pump speed), can limit 
maximum pump speed, and can check pressure data integrity and discern 
anomalous pressure data to discern invalid pressure data from the pressure sensor 
pod 1842. In the event the pump pod 1844 detects invalid pressure data, the 
control software in the pump pod 1844 can exit the Pressure Servo Mode and 
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maintain the current speed of the pump 1864 while alerting the user to the 
condition. 

[00143] Additional safety conditions can also be set up, to operate within or 

in harmony with the Pressure Servo Mode. For example, the pump pod 1844 can 
move from the Pressure Servo Mode into the Back Off Response Mode when 
either an excess pressure or an excess pressure condition is detected. In exemplary 
embodiments of the invention, the mode can return from the Back Off Response 
Mode to the Pressure Servo Mode, with the backed-off flow rate becoming the 
new set point of the Pressure Servo Mode. The user can be alerted each time 
operation shifts from one Mode to another, and can also be alerted when a Mode 
is suspended. The pressure pod 1842 can also be arranged or configured to take 
certain actions when it detects specific conditions, for example by sending an alert 
signal when an excessively low or high pressure is detected. The pump pod 1844 
can be configured to appropriately respond to such trigger messages, for example 
by stopping or pausing the pump 1864. 

[00144] In an exemplary embodiment of the invention, two or more of the 

fluid pumps are controlled in a Master-Slave Servo Mode. In this mode, one or 
more pumps is slaved to the behavior of another pump. The pumps can, for 
example, be centrifugal or roller pumps. In an exemplary implementation of the 
Master-Slave Servo Mode, the pumps 1864, 1866 are both roller pumps, and are 
applied to mix a drug with a patient's blood in order to deliver the drug to the 
patient. In this example, the pump 1864 is the master pump, and the pump 1866 is 
slave pump. The master pump sends its pump speed to the slave pump, and the 
slave pump uses the pump speed from the master pump as a control signal to 
maintain a slave pump speed that is a fixed percentage of the master pump speed. 
The percentage can be a fraction that is less than one, or a fraction that is greater 
than one. The master pump responds to all trigger conditions, and can also operate 
in the Flow Servo Mode or the Pressure Servo Mode. When the slave pump is in 
the Master-Slave Servo Mode, it emulates the master pump's behavior at the fixed 
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percentage or ratio, regardless of which mode the master pump is in. In an 
exemplary embodiment of the invention, If the slave pump cannot maintain or 
achieve the pump speed at the required level, for example if the slave pump 
cannot keep up with the master pump, then the slave pump alerts the user of this 
condition. 

[00145] In an exemplary embodiment of the invention, each pump is 

equipped with a small display screen and an internal pod, and can display a flow 
rate and/or cumulative volume of fluid passing through the pump. The master 
pump can also be configured by the main controller 20 to display a combined flow 
and/or cumulative volume of the slave and master pumps. For example, software 
in the pump pod can determine these values based on a known tubing size or 
capacity of the pump(s), the speed(s) of the pump(s), and elapsed time. The pod 
can receive the tubing size or capacity information from the main controller 20, 
for example during initial configuration. 

[00146] The Master-Slave Servo Mode allows two standard pumps to 

replace a traditional double-headed pump or a pump with dual feeds (which 
requires specialty tubing sets), and can be easily and rapidly configured in 
different ways. 

[00147] As those skilled in the art will recognize, the Back Off Response 

Mode, Flow Servo Mode, Pressure Servo Mode and Master-Slave Servo Mode 
can be used separately, independently, and/or in various simultaneous or 
complementary combinations. The specific mechanism by which a pump pod 
controls the speed of a pump to a specific value or setpoint, can include 
conventional feedback control such as proportional-integral (PI) or 
proportional-integral-derivative (PID) control. 

[00148] Since numerous additional modifications and alternative 

embodiments of the invention will be apparent to those skilled in the art 
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in view of the foregoing description, the above description is to be construed as 
illustrative only, and is for the purpose of teaching those skilled in the art the best 
mode of carrying out the invention. The details of the structure may be varied 
substantially without departing from the spirit of the invention, and the exclusive 
use of all modifications which come within the scope of the appended claims is 
reserved. 



